java映射到基元类型的HashMap的快速替代方案是什么？

Question

首先，让我告诉你们，我已经阅读了之前提出的以下问题，我有一个类似的问题

我想做的是从《纽约时报》文本中获取大量依赖项，这些依赖项将由斯坦福解析器进行处理，以提供依赖项，并将依赖项及其分数存储在hashmap中，也就是说，如果我两次看到依赖项，我会将hashmap的分数增加1

这项任务开始得很快，大约每秒10句话，但速度很快。在我的hashmap中，30000个句子（假设每个句子中有10个单词，我存储的每个单词大约有3-4个依赖项）大约有300000个条目

如何提高hashmap的性能？我可以使用哪种哈希键

非常感谢 马丁诺斯

编辑1：

好吧，伙计们，也许我的问题措辞错误，好吧，字节数组没有在我的项目中使用，而是在上面另一个人的类似问题中使用。我不知道他们用它干什么，所以我问

第二：我不会发布代码，因为我认为这会让事情很难理解，但这里有一个例子：

用一句话：“我要睡觉了”我有依赖性： （我是，-1） （一，走，-2） （一至三） （上午，走-1） . . . （到，床-1） 所有句子（1000000句）的这些依赖关系将存储在hashmap中。 如果我看到一个依赖项两次，我将得到现有依赖项的分数并加1

差不多就是这样。一切都很好，但在hashmap中添加句子（或检索）的速度在这一行上有所下降： 依赖银行。put（newDependancy，dependancyBank.get（newDependancy）+1）； 谁能告诉我为什么？ 当做 马丁诺斯

Answer 1

Trove针对键或值为基元类型的情况优化了哈希映射

然而，这在很大程度上取决于密钥的结构和哈希代码的明智选择

你问题的这一部分不清楚：The task starts off really quickly, about 10 sentences a second but scales off quickly. At 30 000 sentences( which is assuming 10 words in each sentence and about 3-4 dependences for each word which im storing) is about 300 000 entries in my hashmap.。但是，您没有说明更大数据的性能。你的地图变大了，这是很明显的。Hashmaps仅在理论上是O(1)，在实践中，您会看到一些性能随大小的变化，这是由于缓存位置减少，以及由于重新灰化引起的偶尔跳转。所以，put()和get()的时间不会是恒定的，但它们仍然应该接近这个值。也许您使用hashmap的方式不能保证快速访问，例如通过对其进行迭代？在这种情况下，您的时间将随着大小线性增长，除非您更改算法，否则无法更改

Answer 2

HashMap有一个重载构造函数，它将初始容量作为输入。您看到的缩放是因为重新灰化，在此期间，HashMap实际上将不可用。为了防止频繁的重新灰化，您需要从初始容量更大的HashMap开始。您还可以设置一个加载因子，该因子指示在重新灰化之前加载哈希的百分比

public HashMap(int initialCapacity)

在对象构造期间将初始容量传递给HashMap。最好将容量设置为在程序执行过程中要添加到映射中的元素数的近两倍

Answer 3

看看番石榴多重映射：http://www.coffee-bytes.com/2011/12/22/guava-multimaps它们的设计基本上是为了保存所有映射到同一个键的事物的列表。这可能会解决你的需要

Answer 4

谷歌的“fastutil”和你会发现一个优越的解决方案，映射对象键的分数

Answer 5

How will i be able to increase the performance of my hashmap?

如果每次get（）或put（）花费的时间超过1微秒，那么您就有一个bug IMHO。你需要确定为什么要花这么长时间。即使在每个对象都有相同hasCode的最坏情况下，性能也不会这么差

What kind of hashkey can i use?

这取决于密钥的数据类型。这是什么

and finally what are byte[] a = new byte[2]; byte[] b = new byte[3]; in the question that was posted above?

它们是字节数组。它们可以用作查找的值，但可能需要不同的值类型